Application servers provide an infrastructure for building distributed transaction processing applications, such as transactional applications, databases, messaging systems (including the Java Messaging System, JMS), conversation state systems, and web services. In a typical multi-tier architecture, such as that described in “Distributed computing with BEA WebLogic server”, by D. Jacobs, in Proceedings Conference on Innovative Data Systems Research, Asilomar, Calif., 2003, incorporated herein by reference, clients submit requests to a cluster of application servers which act as a front-end to a collection of databases. In most instances, transactional data is maintained in the databases and is accessed from the application servers as requests arrive. However, this arrangement is less than ideal for data such as messages and business workflow state which are used only by the application servers rather than being shared with other enterprise applications; data which is relatively transient in that it is processed by the application servers and then discarded; or data which is accessed in limited ways, for example, by key or through a sequential scan, rather than through arbitrary queries.
Performance and scalability of the system can be dramatically increased by distributing such data across transactional file stores, each of which is bound to an instance of the application server in the cluster. This architecture moves the data closer to where it will be processed, eliminates contention for the data, and permits optimizations around the specific access patterns. Moreover, tight integration of the filestore with the application server simplifies management and administration of the overall system. Specialized file-based message stores are common for all of these reasons, and can be generalized to include other kinds of data. In particular, placing business workflow state in the same store as its associated messages eliminates the need for two-phase commit between the messaging system and databases.
A factor that must be considered with such systems is that transactional applications, such as databases and messaging systems, make extensive use of synchronous writes. In this process, data is transferred to the physical disk medium before the caller is notified of the completion of the operation. Synchronous writes present a significant obstacle to system performance because, unlike other disk operations, their cost cannot be reduced by caching. The cost of a synchronous write is generally dominated by the time it takes to position the disk head, especially in the case of the small writes that are common in transactional applications. This rotational latency means that transactional writes to disk are a potential bottleneck to system performance.
Disk schedulers attempt to reduce the cost of transaction applications and synchronous writes by selecting blocks that are about to rotate under the disk head. Traditional disk schedulers are implemented at a low-level, in a device driver or disk firmware, and schedule writes to the entire disk on behalf of the operating system. They generally rely on information about drive geometry that is obtained in platform-specific ways. However, one of the problems with the traditional approach to providing file stores and disk schedulers are that they are inherently platform-specific. If the application server is to be used in a different hardware environment or in a different usage setting then it must be ported to that platform or setting. This is prohibitive in terms of development and maintenance costs. What is needed therefore, is a platform-independent means of providing a file store or disk scheduler. Such platform independence would allow an application server to be optimally used in different hardware and usage settings without the need for expensive development, porting. and maintenance costs.